NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/18231

Internet Message Format | 1996-08-05 | 7.4 KB

Path: ix.netcom.com!news
From: Bradd W. Szonye <[e-mail]>
Newsgroups: comp.lang.c++
Subject: RE: Would/Won't you use a garbage collector?
Date: 19 Apr 1996 08:40:41 GMT
Organization: Netcom
Message-ID: <01bb2dcc.2dbc15e0$[e-mail]>
References: <4kamie$[e-mail]> <4kg6co$[e-mail]>
NNTP-Posting-Host: det-mi6-06.ix.netcom.com
X-NETCOM-Date: Fri Apr 19  3:40:41 AM CDT 1996
X-Newsreader: Microsoft Internet News


On Wednesday, April 10, 1996, Ian Johnston (by ubsswop) wrote...
> In article <4kamie$[e-mail]>,
[e-mail](Giuliano Carlini) writes:
> |> I'm a long time proponent of using garbage collection in C and C++
> |> programs, and I'm curious:
> |>     - How many others are there?
> |>     - Why don't most C/C++ programmers use it?
>
> [...]
>
> |> What follows is my belief for why garbage collection is so little
used.
> |> Feel free to respond to anything I say below, but please, first
respond
> |> to the questions above. I believe that most people don't use garbage
> |> collection because either they:
> |>     - don't know what it is
> |>     - don't know it can be used with C/C++.
> |>     - are misinformation
> |>     - are biased against it by the C/C++ culture
>
> I think the reasons you give are correct. I also agree that for many
(simple)
> systems, garbage collection (GC) is a good idea.
>

Agreed. For certain specialized applications, GC is great. However, I'm
reluctant to use it, given the "resource acquisition is initialization"
idiom in C++, described by Stroustrup and implemented through constructors
and destructors. This idiom is very powerful, and best of all it comes
*free* with the language.

> I would have no objection to GC being the default for C++,
> provided that I could switch it off and incur *minimal penalty* by
> overriding the GC. That is, minimal performance penalty induced
> by the garbage collector, even though it is not used. A performance
> penalty equivalent to virtual vs non-virtual function calls would be
acceptable.

Which brings me to my next point. One of the most important design
criteria in C++ is that a language or library feature should impose *no*
cost on a program that doesn't use it. (Stroustrup concedes that it is
very difficult, although not impossible, to implement exception handling
without saddling programs that don't want it.)

> Remember too, that GC in C or C++ is *hard*. C has been around
> for 25 years or so, and C++ for about 15; it is only relatively recently
that
> efficient garbage collectors have appeared for C and/or C++. It is not
so much
> that the culture set out biased against GC, but the culture has probably
> grown that way, for the first of the three reasons you give above.

Garbage collection isn't hard. It's been around longer than C (at least as
long as LISP, of the FORTRAN era), and good algorithms appeared in the
60's and 70's, even better ones recently. It isn't GC that's hard, it's
finding the pointers. LISP makes it easy. C/C++ makes it darn near
impossible without bulking out pointers or doing weird runtime data
analyses. (By the way, I don't think many C++ programmers are unaware that
GC exists. They just avoid it like the plague since naive GC routines--a
la VIC-20 BASIC--can be *very* slow).

> [...]

> Third, in the code I write, I use a variety of helper classes to help
manage
> memory (and other resources; see below). I don't tend to use C-style
arrays
> (stack or heap-based). I don't tend to use raw C++ pointers. These
things
> dramatically reduce the potential for bugs. In addition, I make frequent
use
> of customised memory allocators to increase performance of
allocating/releasing
> space for objects. Sometimes I use shared memory. Sometimes I use
statically
> allocated memory. Sometimes I use heap memory.

Sounds like you program the same way I do.

> Unfortunately, there are leaks in the C libraries I use. If a 100%
reliable
> GC could somehow be confined to the library, that would make life
easier. As it
> is, I have to pick and choose the C library routines I use. Sadly, some
can't
> be avoided. This is an argument for GC, rather than against :-)

Fortunately this becomes less of a problem as vendors become "freer" with
their source code; frequently you can fix bugs before the next release of
the library. And fixing bugs is better than relying on another 3rd-party
tool to provide GC. I always trust my *own* code first. (I risk sounding
paranoid).

> Fourth, the code I write lives in a mixed-language environment...

Yuck. Forget about just about any advanced language feature. This makes
exceptions, classes, static objects, whatever-you-like difficult.

> These are the practical reasons. There is another, major reason which is
> partly practical and partly philosphical...

This is the most important point, I think.

> [much good stuff deleted to save you from reading it 2-3 more times]
> [be sure to read the original to learn about resource acquisition]

>
> Ian
>

Stroustrup does an excellent if brief discussion of GC and resource
acquisition/release in "The Design and Evolution of C++" if my memory
serves me. I'll paraphrase him and add my own opinions to say that GC is,
in *general* inappropriate for large C++ systems. The trouble with GC and
C++ is there are lots of situations in C++ where you can't use it.

Take, for instance, just about anything that isn't memory-related. Many
classes (such as almost all of iostreams) does something important in the
destructor. In the case of fstreams, it's closing a file, which is
something you usually want done now, not eventually. In the case of most
of the Microsoft Foundation Classes (MFC) or Object Windows Library (OWL),
a lot of destructors affect what you see on the screen. Those destructors
need calling at a known time for heap objects.

On the other hand, stack objects are very good at managing memory and
other resources. The only pointers you really need to use in C/C++ on a
regular basis are for strings, lists, and trees. The C++ standard is due
to go to ISO in July, and around that time we'll have classes to manage
strings, lists, and trees. Meaning you can hide those pointers in standard
classes. Teach someone to use the C++ library and they won't need to worry
about pointers a lot, only iterators. Iterators are generic pointers
without the related resource headaches, since the classes that generate
them do the resource management. You can do this in your own code by
newing your pointers in constructors and deleting them in the
destructors.

So there's a couple problems or a couple solutions/alternatives to GC. Its
utility is fairly limited in C++, and the language provides a built-in
alternative to GC. A little discipline and a little help from the library
can minimize the opportunities for memory leaks to occur.

Ian brought up the biggest problem with GC: given all the places where GC
is unusable (important destructors) or unnecessary (stack objects), it's
too easy to be careless with GC in the places where it does count. How
easy is it to get in the habit of "The GC system will clean it up"?
Nowadays memory isn't the most limited resource, especially if you're
still using Windows 3.1; if you depend on GC to clean up your memory
garbage, you're likely to be careless about your other garbage. Garbage is
garbage, and GIGO is no longer an accepted computing paradigm. Leave GC to
the languages that hide pointers and cleanup from the user entirely, like
LISP and BASIC.

Bradd W. Szonye